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Remarks 

Claims 1-19 are currently pending in the subject application and are presently under 
consideration. Claims 1 and 19 have been amended herein to further emphasize aspects of the 
subject invention. A version of all pending claims is located at pages 2-5 of this Reply. 
Favorable reconsideration of the subject patent application is respectfully requested in view of 
the comments and amendments herein. 



I. Rejection of Claims 1-19 Under 35 U.S.C. $101 

Claims 1-19 stand rejected under 35 U.S.C. §101 because the claimed invention is 
directed to non-statutory subject matter. Withdrawal of this rejection is requested for at least the 
following reasons. Claims 1-19 produce a useful, concrete, and tangible result. 



Because the claimed process applies the Boolean principle 
[abstract idea] to produce a useful, concrete, tangible result ... on 
its face the claimed process comfortably falls within the scope of 
§101. AT&T Corp. v. Excel Communications, Inc., 172 F.3d 
1352, 1358. (Fed. Cir. 1999) (Emphasis added); See State Street 
Bank & Trust Co. v. Signature Fin. Group, Inc., 149 F.3d 1368, 
1373, 47 USPQ2d 1596, 1601 (Fed.Cir.1998). The inquiry into 
patentability requires an examination of the contested claims to 
see if the claimed subject matter, as a whole, is a disembodied 
mathematical concept representing nothing more than a "law of 
nature" or an "abstract idea," or if the mathematical concept has 
been reduced to some practical application rendering it "useful." 
AT&T at 1357 citing In re Alappat, 33 F.3d 1526, 31 1544, 31 
U.S.P.Q.2D (BNA) 1545, 1557 (Fed. Cir. 1994) (emphasis added). 

In the subject Office Action it is contended that the claims do not produce a concrete, 
useful and tangible result. More specifically, the subject Office Action admits that an 
appropriate utility has been disclosed, but contends that the claims must necessarily require XML 
items to be output and processes to be performed for those items to be 'available' and a tangible 
result to be achieved. (Office Action p. 12, 3 rd paragraph, lines 1-5 and p. 14, 1 st paragraph, lines 
4-6). Applicants' representative submits that this argument is neither supported by case law nor 
grounded in the knowledge of one with ordinary skill in the art. 
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The Office Action contends that a result is not tangible because, although it is an XML 
item that can be output from the claimed transformation system (see Office Action p 14, 1 st 
paragraph, lines 3-7), the claims do not specifically require it to be output from the system, and 
the XML item is not available and no tangible result is produced. The case law, however, does 
not equate the tangible requirement with the term 'available' as the Office Action suggests. 
Instead it requires an inquiry into the claimed subject matter as a whole to determine whether it 
has been reduced to a practical application that renders it useful. The claimed system transforms 
input XML items into other XML formats and can output those transformed XML items to other 
processes or users. An XML item refers to a XML document containing text and other 
information. Text and information are certainly tangible results as required by the case law. 

The Office Action further attempts to characterize these transformed XML items as 
intangible by suggesting that they are not available to a user, and that no actual result is ever 
produced. It concludes that because no result is produced the requirement of a useful, concrete 
and tangible result is not met. The suggestion itself is logically incorrect however; one of 
ordinary skill in the art would consider the fact that an XML item can be output from a system 
as implying that it is available to the appropriate user. It is unfathomable to require that data be 
freely available without restriction for it to be considered 'available'. Although the claims recite 
no limitation placed on a user's access to an XML item, the Office Action concludes that the 
result of the claimed subject matter is unavailable. This line of reasoning does not fit the 
relevant art. 

For example, one of skill in the art would likely consider the term 'available' to mean 
present or ready for immediate use. The simple fact that data can be output to a user means that 
it is ready for immediate use, and thus available. To use a simple analogy, produce items sold at 
a grocery store are perhaps universally considered 'available' even though there might still be 
qualifications on whether that produce is actually given, or output, to a customer. The fact that, 
for example, the customer may have to first find, gather, present, and tender compensation for 
those produce items, and be capable of doing so, does not render the grocery store's products any 
less 'available' to the consuming public in the mind of a skilled produce shopper. In a non- 
physical analogy, television and radio communications are often considered freely available, 
even though a user may not have an antenna to receive the carrier signal, a device to decode it 
and a medium to display the communications. Someone without a requisite device would not be 
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able to 'output' the communication, but to say that it is unavailable is inaccurate. Likewise, one 
skilled in the art of XML data transformation would certainly consider text and information in 
the form of a XML document that can be output from a data manager to be 'available', even 
though, at some point in time, it has not already been output to him, or even though there might 
be some restrictions on whether it ever is actually output to him. Nothing in the case law 
requires a concrete, tangible and useful result be accessible without restriction to all users, and 
the Office Action goes too far in its implication that the case law does so require. Applicants' 
representative therefore submits that it should not be necessary for a result, such as that produced 
by the claimed subject matter, to be output without limitation to the user for one skilled in the art 
to consider that result to be useful, concrete and tangible. Consequently, applicants' 
representative further submits that a transformed XML item recited in claims 1 and 19, that can 
be output to a user or subsequent process, is a useful, concrete and tangible result and thus 
statutory subject matter. 

Similar logic is applicable to the Office Action's contention that transformation processes 
must actually be performed for a tangible result to be achieved. It is not clear why such 
processes must be performed without limitation for the result of the process, once initiated, to be 
tangible. Neither does the Office Action provide any support for its contention. The appropriate 
inquiry is whether a claimed invention is reduced to some practical application rendering it 
useful. (See AT&T at 1357 citing In reAlappat, 33 F.3d 1526, 31 1544, 31 U.S.P.Q.2D (BNA) 
1545, 1557 (Fed. Cir. 1994) (emphasis added)). An application merely needs to be capable of 
producing a useful, concrete and tangible result for it to be practical. To require that no 
limitation whatsoever be placed upon achieving the result likely goes further in rendering a 
process useless, considering the need to secure information, than any restriction on whether the 
process is ultimately performed or the result eventually output. 

Applicants' representative further notes that the subject Office Action has failed to 
address the arguments submitted in the prior response, Reply to Final Office Action Dated July, 
1 8 2006. Specifically the holding of the Court of Appeals for the Federal Circuit in Eolas 
Techs., Inc. v. Microsoft Corp., 399 F.3d 1325 (Fed. Cir. 2005): 

Title 35, section 101, explains that an invention includes "any new 
and useful process, machine, manufacture or composition of 
matter." ... Without question, software code alone qualifies as an 
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invention eligible for patenting under these categories, at least as 
processes. Id. at 1338 (emphasis added). 

The subject claims clearly pertain to software code comprising a transformer or 
transformation component that transforms one or more input XML items in a first format to one 
or more transformed XML items in one or more second XML formats and an output manager 
that facilitates at least one of selectively pulling and pushing a subset of the one or more input 
XML items that facilitate the transformation and transmission of XML items. The XML items 
input to the system can contain software code, and the components within the transformation 
system can contain software code that effectuates a process for data transformation. It is 
submitted that all that is relevant is the fact that software code is received, processed, and can be 
output by a system, and such software produces a useful, concrete, and tangible result. 
Applicants' representative reiterates these arguments herewith and requests that the Office 
consider the claims in light of this recent, and clearly relevant, Federal Circuit decision. 

In view of at least the foregoing, it is readily apparent that the subject claim sets forth a 
useful, concrete and tangible result. Accordingly, withdrawal of this rejection is requested. 

II. Rejection of Claims 1-19 Under 35 U.S.C. §103(a) 

Claims 1-19 stand rejected under 35 U.S.C. § 103(a) as being unpatentable over 
ADO.NET (English Translation) and further in view of Omoigui (U.S. 2003/0126136 Al). 
Applicants' representative submits that in light of the amendment made herein the rejection 
should be withdrawn for at least the following reasons. ADO.NET and Omoigui, either alone or 
in combination, do not teach or suggest each and every aspect set forth in the subject claims. 

To reject claims in an application under §103, an examiner must 
establish a prima facie case of obviousness. A prima facie case of 
obviousness is established by a showing of three basic criteria. 
First, there must be some suggestion or motivation, either in the 
references themselves or in the knowledge generally available to 
one of ordinary skill in the art, to modify the reference or to 
combine reference teachings. Second, there must be a reasonable 
expectation of success. Finally, the prior art reference (or 
references when combined) must teach or suggest all the claim 
limitations. See MPEP §706.02(j). The teaching or suggestion to 
make the claimed combination and the reasonable expectation of 
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success must both be found in the prior art and not based on 
applicant's disclosure. See In re Vaeck, 947 F.2d 488, 20 USPQ2d 
1438 (Fed. Cir. 1991) (emphasis added). 

Claims 1 and 19 have been amended herein to recite a transformer or transforming 
component that ". . .transforms one or more input XML items in a first format to one or more 
transformed XML items in one or more second XML formats. . . ." It is submitted that the 
specification as originally filed supports this amendment to claims 1 and 19, because one of 
ordinary skill in the art would clearly know that XML items are organized via XML formats. 
Thus, as required by 35 USC §1 12, the specification as originally filed fully enables the claims 
as amended to one of ordinary skill in the art. 

The claimed invention discloses a system and method for providing a streaming input and 
streaming output incremental XML transformer that can be employed in push and/or pull model 
processing. The XML transformer provides for incrementally building output from XML data 
by loading a subset of an XML document into memory to perform a selective transformation. 
More particularly, independent claims 1 and 19, as amended, recite similar limitations, namely a 
transformer or transforming component that transforms one or more input XML items in a first 
format to one or more transformed XML items in one or more second XML formats. 
ADO.NET and Omoigui are silent with regard to such novel aspects. 

ADO.NET generally relates to XML data and, as far as can be determined from the 
disclosure, discloses an XMLReader and a component that provides XML, XSL, XSL/T, and X- 
Path tools presumably utilized by the XMLReader to produce a XMLDataDocument. Insofar as 
it can be determined from the disclosure in the reference, the ADO.NET system receives XML 
documents as input to facilitate the composition of a XMLDataDocument object containing the 
individual XML documents. However, it is submitted that the claims as amended clearly recite 
the result of the transformation of "one or more input XML items in a first format" is an XML 
item, since only an XML item would have "one or more second XML formats". Accordingly, 
the reference's disclosure of a data set object is not equivalent to transforming one or more input 
XML items in a first format to one or more transformed XML items in one or more second 
XML formats. 

In addition, it is noted that in previous correspondence applicants' representative 
submitted that ADO.NET did not provide a comprehensible description of its activities sufficient 
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to enable one of ordinary skill in the art to effectuate the disclosure therein without undue 
experimentation. (See Reply to Office Action dated July 18, 2006). The subject Office Action 
replied to this submission by stating that this conclusion was merely applicants' representative's 
opinion, and that no further factual information was supplied to corroborate this claim. Contrary 
to the Office Action's claim, and in light of the information submitted infra, it should be clear 
that ADO.NET does not enable subject matter reading on independent claims 1 and 19. 

First, applicants need not present sufficient facts rebutting the reference because the 
Office Action has not provided a prima facie case that the reference enables the subject matter it 
purportedly teaches. The Office Action relies on figure 1 at page 4 of ADO.NET to contend that 
transforming one or more input XML items in a first format to one or more transformed XML 
items is disclosed in the prior art. (See Final Office Action dated August 2, 2005, par. 20, p. 8, 
lines 15-19). However, for a drawing to constitute an enabling reference, it must show the 
claimed structural features and how they are put together. (Jockmus v. Leviton, 28 F.2d 812 (2d 
Cir. 1928); MPEP §2121.04; See MPEP §2125). The Office contends that the ADO.NET 
reference discloses the stated elements of Claims 1 and 19 via the XMLReader, 
XMLDataDocument, and various XML items (XML, XSL, XSL/T,X-Path inquiries etc), but 
fails to specify how the reference puts together these components or how they might read on the 
subject matter recited in the claims. The figure at page 4 of ADO.NET does not show the 
XMLReader operating on any component other than the XMLDataDocument itself. It is not 
clear how this object can transform one or more input XML items into transformed XML items 
when the figure shows it as having either an input, or an output e.g. the XMLDataDocument, but 
not both. 

Further, an arrow drawn between a box with XML items (XML, XSL, XSL/T, X-Path) 
and a box with XMLDataDocument hardly implies that those items are transformed from one 
XML item to another. It may be conceivable that this happens, because the reference does not 
specify one way or the other, but that hardly constitutes showing the claimed system or showing 
how the features are put together. The XMLDataDocument may operate on the XML items, may 
simply be associated with them, may utilize them in another operation, or the opposite may occur 
e.g., the XML items themselves may be the operators which associate with or operate on the 
XMLDataDocument, or none of it may occur. Whatever ADO.NET teaches, neither the 
reference nor the Office Action shows a transformer that transforms one or more input XML 
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items in a first format to one or more transformed XML items in one or more second XML 
formats. Therefore, because the face of the reference does not disclose the claimed subject 
matter and the Office Action fails to specify further, it is submitted that the Office Action has 
failed to meet its burden of producing a prima facie case of obviousness under 35 USC §103, and 
that any burden to present facts to the contrary has not fallen to applicants. {See MPEP §2142). 

Second, contrary to the Office Action's contention, the prior response clearly does outline 
specific deficiencies in the level of detail set forth in the ADO.NET disclosure to establish 
ADO.NET as a non-enabling reference in regard to the claimed subject matter. Nothing in the 
reference clearly articulates any of the methods of operation relied on by the Office. {See Reply 
to Final Office Action dated July 18, 2006) For example, the lone figure that presumably 
represents a schematic of the entire system does not explain the arrows connecting individual 
components, thus leaving the true functionality open to interpretation and conjecture {See page 5; 
see also supra). Moreover, many sections within the reference provide only a listing of terms 
without definitions or explanations that would enable one to understand the system's 
functionality {See page 9). 

Furthermore, ADO.NET is wholly unclear as to what kind of process the XMLReader 
uses to produce a XMLDataDocument or whether the XMLDataDocument actually is the final 
result of some process associated with the XMLReader. As stated supra, the figure does not 
specify. Moreover, there seems to be no direct link listed anywhere in the reference connecting 
the XMLReader with some final output data, the Office Action inaccurately states this result. 

In another example, the Office contends that ADO.NET expressly states that the 
XMLDataDocument object checks/corrects XML documents within the XMLData object (Office 
Action dated January 24, 2006, paragraph 17, p. 7, lines 1-5). However, ADO.NET at page 17 
certainly does not state this expressly. At best, it lists "checking/correcting XML documents 
within the XMLData object" underneath a subheading entitled "XmlDataDocument", not 
specifying whether it is a function performed by the "XmlDataDocument", as the Office Action 
claims, or merely some action peripherally associated with it. This is but one example of the 
ambiguities littered throughout this document. The figure on page 4 does not illustrate a 
XMLData object or a XML document, interacting with the XMLDataDocument or otherwise. 
This suggests that either they are contained within the XML, XSL, XSL/T, or X-Path inquiry 
items, or within the XMLReader itself, since those are the only items that are shown to interact 
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with the XMLDataDocument. However, this conclusion itself is pure conjecture, unsupported 
by the reference itself, because the entire ADO.NET reference does not mention any such 
relationship. Certainly there is no support for the contention that ADO.NET "expressly states" 
that the XMLDataDocument object checks/corrects XML documents within the XMLData 
object. At most the reference merely associates them in some undisclosed manner, but then just 
as effectively disassociates them by providing no relationship between these items in the figure 
or anywhere else in the document. 

Applicants' representative maintains that despite the proffered English translation of 
ADO.NET the cited document does not provide an enabling reference for the purported 
teachings asserted by the Examiner. 

In regard to the Omoigui reference, Omoigui fails to teach the subject matter of amended 
claims 1 and 19, specifically a transformer or transformation component that ". . .transforms an 
input XML item from a first format to a transformed XML item in one or more second XML 
formats. . ." and therefore fails to cure the deficiencies of ADO.NET. 

In view of the foregoing, it is believed that neither ADO.NET nor Omoigui, alone or in 
combination, teaches or suggests each and every aspect of independent claims 1 and 19 (and 
claims 2-18 that depend there from). Therefore, it is respectfully requested that this rejection be 
withdrawn. 
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Conclusion 

The present application is believed to be in condition for allowance in view of the above 
comments and amendments. A prompt action to such end is earnestly solicited. In the event any 
fees are due in connection with this document, the Commissioner is authorized to charge those 
fees to Deposit Account No. 50-1063 [MSFTP296US]. Should the Examiner believe a telephone 
interview would be helpful to expedite favorable prosecution, the Examiner is invited to contact 
applicants' undersigned representative at the telephone number below. 



Amin, Turocy & Calvin, llp 
24 th Floor, National City Center 
1900 E. 9 th Street 
Cleveland, Ohio 44114 
Telephone (216) 696-8730 
Facsimile (216) 696-8731 



Respectfully submitted, 
Amin, Turocy & Calvin, llp 

/Himanshu S. Amin/ 

Himanshu S. Amin 
Reg. No. 48,064 
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